ByQI服务端接口测试智能解决方案

ByQI是Quality Lab团队开发的智能化、无人值守全自动化服务端接口验证工具。可提供：针对各业务线通用的基础接口全自动化检测能力 + 业务线定制测试增强能力。

一、背景

在当前软件研发流程中，接口测试是质量保障的重要一环，业界主要通过接口测试框架或diff平台来实现自动化，前者实现了用例的执行能力，后者在原始流量回放的基础上实现了的diff断言能力。

但是，在测试用例生成、用例执行、结果断言、问题定位等高人力成本的环节，尚未有较完整的解决方案或能力的打通融合，这也是质量团队人效提升的关键瓶颈。

ByQI 的诞生，就是期望以智能化手段解决传统服务端接口测试所面临的如下问题：

• 手工构造用例覆盖度低，丰富度受限于经验值

• 人力成本及维护成本高，测试流程中需要大量的人工介入

• 数据消费质量差：测试与研发流程未形成闭环，RD问题定位困难

• 实际测试中，有大量有价值数据未得到充分挖掘利用

二、目标

区别于测试框架和diff工具，ByQI致力于实现服务端接口验证的全流程无人值守闭环，即提供用例生成、用例执行、结果断言、问题定位的全流程能力；并充分利用AI模型学习能力，深度挖掘测试流程中的历史数据，以真正实现对服务端接口的智能化、自动化闭环测试。

三、设计方案

3.1 整体流程

ByQI整体方案可描述为以下几个主要环节：

1.用例采集

ByQI从TCP层获取HTTP或RPC流量的原始请求，解析后得到原始请求数据。

2.数据合规脱敏

获取到原始请求数据后，将header/query/body部分的cookie等用户身份字段进行替换，避免干扰真实用户；同时对电话、住址等隐私信息识别后进行打码，保护隐私数据。

3.用例及预期值生成

a. 单接口用例方面，ByQI能够生成正向组合用例和负向用例，实现对边界逻辑和异常逻辑的全面覆盖；
b. 场景化测试方面，针对有前后依赖的一系列场景化接口，ByQI能够梳理前后依赖关系形成场景化用例集合；

正向用例：对已知入参通过算法进行组合以验证代码边界等逻辑问题

负向用例：通过改变入参类型等方法验证代码的异常处理能力和鲁棒性等

4.用例执行

基于流水线或定时任务，ByQI可以对HTTP/RPC服务进行接口回归验证。

5.结果断言

对于实际请求的响应值，ByQI通过schema校验、精准值校验等方式与预期值进行对比，断言用例是否通过。

3.2 能力矩阵

ByQI主要能力如下

用例生成层面：具备了场景化用例的构造、正向用例的自动化组合、负向用例的构造能力。

触发方式层面：支持发布流水线触发接口验证、定时任务触发接口验证以及7*24不间断执行的功能+性能+稳定性的验收能力。

详细进展如图

3.3 核心痛点及解决方案

基于ByQI突出的核心能力建设，ByQI能够有效地解决接口测试的多个痛点

(一) 非幂等接口测试

目前的接口测试中，手动case可通过梳理业务逻辑、构造测试账号的方式覆盖非幂等接口，而自动化用例构造及执行中，为避免误判导致线上数据污染，通常选择不执行非幂等接口 ；这导致测试范围有限，无法覆盖更多的核心场景，甚至是问题逃逸至生产环境。

ByQI提出一种非幂等接口的mock方案：

• 基于链路拓扑识别写操作的非幂等接口
• 针对非幂等接口录制入流量与出流量生成匹配的mock数据
• 用例执行时根据链路拓扑识别写操作进行mock

(二) 场景化测试

随着软件逻辑的复杂度提高，单接口测试逐渐无法满足测试需求，与之对应的是具有前后依赖关系的场景化接口和用例。但场景化接口的业务逻辑梳理、用例编写、参数调用关系梳理、场景化用例回放执行是限制业务同学进一步提升测试覆盖率、降低人力成本的痛点问题。

以在线直播场景为例：直播业务场景化接口占比较高，包含例如不同直播房间、存在主播与关注身份差异、存在主播与观众间的互动请求、以及关注/ 游戏/ 送礼等诸多操作；接口间参数存在相互依赖的关系，单独执行某个接口成功率极低，如果不解决场景化接口的自动化采集/ 测试问题，则无法大幅提升接口测试的覆盖度及准确率。

ByQI提出基于调用链路DAG图的场景化用例构造方案

1.全流量case采集及存储：

采集全量API层流量数据，存储前，完成数据安全/ 合规检测、识别、加密/脱敏；

2.场景请求及边界确定：

    a. 从db中获取场景元信息：（脱敏用户唯一标识, 开始时间, 结束时间）

    b. 从流量库中捞取N条请求链路，并求解公共请求[根据上面得到的 N 条序列可以计算出该场景下必须的请求（这里就是 N 条序列的最长公共子序列）]

    c. 通过MLCS+转移矩阵优化算法以增强鲁棒性，避免采样率造成的公共请求路径遗漏；

3.场景化接口参数关系梳理及DAG图构造

基于请求源IP、query、body 等参数，通过排序、构建链接关系等方法，绘出一个有向无环图(Directed Acyclic Graph)；

4.场景维度用例执行 + 断言校验

以在线直播场景为例

• 执行前：
• 获取测试环境有效用户cookie/session等
• 创建直播间

• 执行场景化用例，如用户进入、送礼物、连麦等

• 执行后:
• 数据清理、关闭直播间

(三) 用例生成能力

当前用例自动生成多采用随机生成(RT)或组合生成(CIT)的方法。RT方法的主要弊端是参数过于随机而没有实际意义，会造成很多无效请求；CIT的主要问题是当录制流量较大时，参数的可选值很多，组合的方法耗时较长。

ByQI通过对以上方法对比研究，提出基于「ART随机生成 + Levenshtein距离 + maxi-min算法筛选」的优化方案

关键名词说明：PSM（服务唯一标识，下同）

各环节说明：

• 流量录制：从实验选定的PSM中录制线上流量（15000条/PSM），将每条流量的Request和Response按键对存储。

• 筛选参数：对于同一个PSM中的每个接口，过滤不相关参数，汇总每个参数的可选值。

• 用例生成策略
• RT（随机生成）：对于每个接口的每个参数，分别从可选值中随机选取，生成一条随机用例。
• ART（自适应随机生成）：自适应随机生成方法是基于随机生成的，主要是通过定义用例间距离metrics，使随机生成的用例之间的离散程度最大化，从而实现更好的覆盖效果。
• CIT（组合生成）：对于所有参数的所有可选值，通过two-pairwise组合的方法生成用例。

从对比结果可以看出，较RT而言，ART方法能获得更高的代码覆盖率，且时间上要优于传统的CIT方法，用例生产效率和性能较高。

(四) 断言准确性

断言是对比预期值和实际响应值是否一致的过程，而是否一致的标准因编写人员的经历、业务理解程度而异，直接影响了用例执行的准确率；ByQI提出了「接口+监控」维度的自动化断言决策逻辑：

• 接口层面
• 首先对状态码、逻辑码进行初步判断
• 支持schema结构断言、值断言以及自定义精准值断言能力

• 监控层面
• 抓取调用链路上下游日志
• 分析服务监控指标

对接口及监控结果进行综合断言聚合，给出最终用例执行结果

下图为监控层面发现的panic、堆栈异常等问题，能够为接口断言提供有力的支撑

(五) 功能+性能验收

BOE(线下测试)环境是RD/QA的重要工作环境，但流量极少，稳定性不足；当前主要依赖QA同学自构流量，普遍量级小、数据噪声多、有效性低；已有工具，使用原始流量携带的参数回放无法复用，回放成功率不达预期；

ByQI提供打通客户端及服务端进行流量构造；对于原生流量极低的服务，通过客户端遍历的方式构造流量生成用例；

同时，在原有能力基础上，实现了一套流量采集、改写、放大、存储、持续性回放解决方案，对测试环境输入大量稳定且有效请求以验证测试环境服务的稳定性。

四、ByQI实践案例

流水线卡点

在服务部署的小流量环节，通过插件卡点的方式向被测服务的小流量实例发送请求，进行回归验证

执行结束后，会产生执行报告及详细统计信息

以某业务线为例，自接入ByQI以来，在某地区的服务覆盖率超95%，问题发现精确率达90%

服务覆盖率 = 业务线该地区接入ByQI的服务数量/业务线在该地区的全部服务数

问题拦截精确率 =  TP / (TP + FP) =  已确认有效问题  / （已确认有效问题 + 符合逻辑、无法复现或无效问题）

接入以来共发现80个问题，详细类型如图

ByQI整体接入服务统计如图

五、未来规划

未来ByQI主要朝着更快、更准确、更强大三个方向发展：

• 更快：主要在研发效率的提升和问题发现的时效性
• 更准确：依托算法能力，强化场景化测试能力，以及结果断言的智能化
• 更强大：在现有HTTP及RPC(thrift)接口验证的基础上，增加对其他协议的兼容和覆盖；并探索问题定位及自动修复能力。